home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 644 < prev    next >
Internet Message Format  |  1994-08-27  |  7KB
  1. Date: Tue, 14 Jun 1994 21:40:24 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: Digest
  4. To: gem-list@world.std.com
  5. In-Reply-To: <9406150025.AA21495@uqcspe.cs.uq.oz.au>
  6. Message-Id: <Pine.3.87.9406142124.A15873-0100000@undergrad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11. Ofir:
  12. ---------------
  13. In message <m0qCsU7-0003oRC@gogol.fb10.tu-berlin.de>,
  14. chris@buran.fb10.tu-berlin.de said:
  15. >
  16. ><arrow left>    hide block, put cursor at left end
  17. ><arrow right>   hide block, put cursor at right end
  18.  
  19. OK.
  20. ---------------
  21. Keep in mind that these are only useful for systems where the block is 
  22. considered to be a "big cursor".  Since I like this system, I agree with 
  23. the above, but  let's not muddle the systems.  If you're going to use 
  24. big-cursor, good, but if you're not, don't confuse people.  There is 
  25. another distinct system (although not well standardized, where the block 
  26. is entirely independant of the cursor, and using the arrow keys does 
  27. nothing more than move the cursor around.
  28.  
  29. Ofir:
  30. ------------------
  31. >> CTRL I -                 Show Info
  32. >
  33. >In text oriented applications I prefer CTRL-I  italic
  34.  
  35. This was in my original proposal but was removed, maybe I should put it
  36. back then.
  37.  
  38. >It could be used alternatively depending on the type of application.
  39. >
  40. >CTRL-B -           bold
  41. ------------------
  42. This is a tough issue.  Block operations are more frequently used than 
  43. are formatting operations (I would suppose), so the block operations 
  44. should be assigned first.  Ctrl-B/E should therefore take presidence.  
  45. However, under a big-cursor system, selecting a block would not quite be 
  46. done by the Ctrl-B/E way.  More involvement with the mouse or use of 
  47. Right-Shift in the manner of Windows would have to be done.  In this 
  48. case, you could use Ctrl-B for Bold and Ctrl-E for something else.  
  49. Someone suggested using the Ctrl or Alt number keys for text attributes.  
  50. While this wouldn't be very mnemonic, it WOULD put the attributes on the 
  51. keyboard SOMEWHERE, and if everyone used it, people would learn it.
  52.  
  53. As for Ctrl-I, I think both are good.  How about allow text apps use it 
  54. for Italic, and others for Show Info.  On the other hand, if you use the 
  55. number keys, then stick with Show Info.
  56.  
  57. Ofir:
  58. ---------------
  59. >
  60. >Alt Del -              Delete to end of line
  61. >Alt BS -               Delete from start of line
  62.  
  63. Since many people have asked me to change this, I propose to make an
  64. exception and use the Alt key for this shortcut.
  65. ---------------
  66. Yes, Yes, Yes!  Thank you, thank you, thank you!
  67.  
  68. Shift Delete and BS should only each delete one character just as the 
  69. unshifted versions.
  70.  
  71.  
  72. Michel Forget:
  73. --------------
  74. This is not the case at all; under a multitasking system, some programs
  75. will write directly to the console.  That will screw up the screen and
  76. no redraw messages will be sent to the application.  It is not the
  77. fault of the application, yet the screen is still messed up.  To date,
  78. though, MultiTOS, Geneva, and Mag!X all have a way to redraw the entire
  79. screen (so these keypresses are not needed).  Still, it is not a good
  80. idea to assume that the screen is always going to be perfect looking.
  81. ---------------
  82.  
  83. In the editor for ANSITerm, if you want to call it that, I did, in fact, 
  84. assign something to Ctrl-A.  It redraws the displays, because this 
  85. editor, if you want to call it that, is not designed to be able to do 
  86. much very well, so it will often not properly update the screen.  As a 
  87. result, whenever I hit Ctrl-A by accident, it goes virtually unnoticed.
  88.  
  89. So, how about we do the same?  Ctrl-A == Redraw screen.  Something easy 
  90. to hit has something totally harmless assigned to it.  Normally, I 
  91. wouldn't suggest this since I would assign something freqently used and 
  92. very productive to key combinations that are easy to hit, but, as I've 
  93. pointed out, Ctrl-A is TOO easy to hit, and therefore, if anything at all 
  94. is assigned to it, it should be totally harmless, and what could be more 
  95. harmless than Redraw window?
  96.  
  97.  
  98. Vincent:
  99. ---------------
  100. I prefer:
  101.   home -           nothing
  102.   shift + home -   move to top of doc
  103.   ctrl + home -    move to bottom of doc
  104. because "home" is near the arrows (partially between up-arrow and
  105. right-arrow) and can be hit by mistake.
  106. ---------------
  107. I partially agree.  I have accidentally hit home before, and it was 
  108. annoying, but it was not destructive.  As long as what Home does isn't 
  109. DANGEROUS, it may be okay to use it.
  110.  
  111.  
  112. Vincent:
  113. ------------------
  114. > However, is the Windows-like "delete a block when typing something new",
  115. > something we need to consider when dealing with this group of 
  116. shortcuts? Or
  117. > should we in general recommend that a block can only be deleted explicitly,
  118. > preferably with a Ctrl-Delete?
  119.  
  120. I prefer the ctrl-delete solution. Moreover, typing text shouldn't deselect
  121. the block.
  122. ------------------
  123. As I've said before, doing this results in an abandonment of a system of 
  124. handling block that is not only well-accepted, but also one that requires 
  125. less work than alternatives.  Nevertheless, in situations where you must 
  126. have a heterogenous command set, there SHOULD be a distinction between 
  127. block and text operations.  Delete should delete a single character, and 
  128. something else should delete the block.  Since Ctrl-Delete is already 
  129. assigned to delete-next-word, it is not a good choice.  Since 
  130. Shift-delete has been de-assigned, and delete to end of line been 
  131. assigned to Alt-Delete, then Shift-delete should be used for delete 
  132. block.  However, whatever you do, do not assign anything but delete a 
  133. single character to Shift-Backspace (we know why), and Shift-delete 
  134. should delete only one character when no block is selected.
  135.  
  136.  
  137. Christian:
  138. ---------------
  139. I think standardisation is more important than free definition by the user
  140. because the majority of users won't bother to redefine shortcuts, and this
  141. will also be less accepted by programmers if they have to include code.
  142. Even I am not sure if I will support this in papyrus. Reassigning shortcuts
  143. is also problematic because in some apps the keyboard is almost full with
  144. shortcuts, so by redefining one is likely to loose a shortcut for an
  145. app-specific function - actually it is unpredictable what will happen when
  146. it is used. That brings me to different idea:
  147. ---------------
  148. I agree with this.  First and foremost, define the STANDARD, THEN think 
  149. about ways of making it configurable.  I know that MANY programmers won't 
  150. want to put in any code to handle configuration of shortcuts (their code 
  151. or not... I'm seldom able to compile someone else's code without 
  152. modification, and I can never read it.).  Face it, people are either too 
  153. busy or lazy.  Either way, only a fraction of apps will support the 
  154. config file.
  155.  
  156.  
  157.  
  158.  
  159.  
  160. You know one things that's missing from RSC files?  The ability to put 
  161. code into the resource file.  Could be useful.  Of course, it would also 
  162. be nice to have a C++ compiler with English docs.
  163.  
  164.  
  165.